In distributed computing, an object request broker (ORB) is middleware used to abstract the communications between software object implementations. When a client sends a request to a server object implementation, the ORB is responsible for locating the server object implementation, for preparing the server object implementation to receive the request, and for transforming the request into a format suitable for transport to the server object implementation. An ORB on the server side is responsible for reconstituting the request for dispatch to the server object implementation. In distributed computing systems utilizing ORBs, the client need only be aware of those aspects of the server object implementation that are reflected in the server object implementation's interface.
Using an ORB, a client can transparently invoke a method on a server object implementation, whether that server object implementation is located on the same machine as the client or is located across a network. The ORB intercepts the communication, locates the server object implementation, transforms the outgoing communication into a format suitable for transport, and reconstitutes any incoming communication from the server object implementation into a format suitable for dispatch back to the client. Thus, ORBs provide interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnect multiple object systems.
In order to achieve such interoperability, ORBs must communicate using a standardized communications protocol known as an inter-ORB protocol. The ORB on the server side must “speak the same language” as the ORB on the client side to ensure proper message interpretation. One such inter-ORB protocol is the General Inter-ORB Protocol (GIOP) as specified by the Object Management Group (OMG) in version 3.0 of its Common Object Request Broker Architecture (CORBA) specification, hereby incorporated by reference in its entirety into the specification of this patent application. The GIOP is designed such that it can be mapped onto any physical transport protocol that meets a minimal set of assumptions. Included in this minimal set of assumptions is that the transport must be connection-oriented, the transport must be reliable, and the transport must be viewable as a low-level octet stream. A low-level octet stream is an uninterpreted sequence of 8-bit octets, and is also referred to as a byte stream. Examples of connection-oriented transport protocols include Transmission Control Protocol (TCP) and Reliable User Datagram Protocol (RUDP). Examples of physical layer transport protocols include Ethernet and RapidIO.
Ethernet-based TCP's latency in highly embedded environments has been cause for concern, especially where the system has a high degree of sensitivity to loss of determinism in request and response latency. As recently as five years ago, examination of the percentage of time spent in the transport stack compared to time spent in the ORB indicated that anywhere from 70-85% of the time was spent in transport compared to only 12-15% spent in the ORB. So ORB overhead was relatively low. More recently, however, the introduction of faster shared memory-based fabric transports and newer fabric standard implementations such as those of RapidIO has caused a reversal in the latency picture. Using such transports, we see 80-90% of total call time now appearing to be in the ORB and far less time now in the transports. Although these faster, more predictable, and deterministic transports have become available, the ORBs have stayed somewhat static in their designs.
Examination of the time spent in an ORB has typically shown that the most CPU intensive and greatest contributor to latency is the ORB's marshalling engine. The marshalling engine is an inter-ORB protocol engine that translates wire traffic from the transport into ORB communications and vice-versa. Because it is desirable to lower call latency as much as possible, and because traditional techniques have focused purely on software based mechanisms and on performing intelligent operations in search of faster, leaner, and more effective GIOP implementations over various transports, a novel approach is desired to accelerate the inter-ORB protocol engine and thus reduce latency.
In computing environments comprising distributed software objects running on processors and hardware objects residing in silicon, custom proxies known as hardware abstraction layers (HALs) have been developed to establish communications between the processors and the hardware objects. These custom proxies are meant to increase portability and re-use, but in practice, they tend to increase latency, reduce throughput and lower re-use. Another communication solution has been to embed general purpose processing cores into hardware platforms alongside the hardware objects in order to offer software-based ORB capability. This approach tends to require significant gate count and memory utilization and generally these processing cores cannot be clocked fast enough to deal with ever-increasing performance requirements. A novel approach is needed to facilitate communications between software objects running on processors and hardware objects residing in silicon.